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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re Patent Application of 
DO 

Serial No. 

Filed: October 5, 1999 

For: ARRANGEMENT FOR SIMPLIFYING THE 
DESIGN AND IMPLEMENTATION OF 
MOBILE SERVICES IN A 
COMMUNICATION SYSTEM 

October 5, 1999 

Assistant Commissioner for Patents 
Washington, DC 20231 

PRELIMINARY AMENDMENT 

Sir: 

Prior to calculation of the filing fee and examination the merits, please amend the above- 
identified application as follows: 

IN THE CLAIMS : 

Please amend claims 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 17, 21, 23, and 25 as follows: 

3. (Amended) Arrangement as claimed in [claims 1 or 2] claim 1 . characterized in that 
said mobility transparency means are introduced to the application designers at the 
requirement and functional specification phases, i.e. > by integrating mobility function (M) 
totally into the infrastructure of a platform. 

4. (Amended) Arrangement as claimed in [any of the preceding claims] claim 1 , 
characterized in that said mobility transparency means are so adapted that computational 
objects are mapped to engineering objects (EO) so as to be none-visible in the computational 
model of the application in question. 

5. (Amended) Arrangement as claimed in [any of the preceding claims] claim 1 . 
characterized in that the mobility function constitutes the engineering object interceptor, i.e. , 
being arranged at the boundary between the terminal domain and the telecom system 
domain, 
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6. (Amended) Arrangement as claimed in [any of the preceding claims] claim 1 . 
characterized in that an engineering model is developed by letting each computational object 
(CO) be mapped to one or more Basic Engineering Objects (BEOs), interaction between 
computational objects (COl, C02) belonging to the same cluster being effected directly as 
method calls, and communications between [computunal] computational objects (C03, 
C04) located in the telecom system domain and in different clusters being effected through a 
channel comprising stubs, binders and protocols. 

7. (Amended) Arrangement as claimed in [any of the preceding claims] claim 1 . 
characterized in that communication between user domain computation objects (C02) and 
telecom system domain computation object (C03) residing in different clusters will take 
place in a channel comprising an interceptor ( ) in addition to the usual objects, said 
interceptor being invisible for the application designer. 

8. (Amended) Arrangement as claimed in [any of the preceding claims] claim 1 , 
characterized in that from the computational model the application designer can decide 
whether an object belongs to the user domain or the telecom system domain, for on the basis 
of such a decision to generate the necessary objects, such as stubs, for all the application 
objects. 

9. (Amended) Arrangement as claimed in [any of claims 1-2] claim 1 . characterized in 
that the arrangement comprises means for sending a message to a routing broker asking for 
specific server to perform a task, said broker locating the server and sending said request to 
said server, said mobility functions (M) thereby playing the role as the broker. 

10. (Amended) Arrangement as claimed in [any of the claims 1-2 or 9] claim 1, 
characterized in that said mobility function (M) comprises a cascade of two brokers. 

11. (Amended) Arrangement as claimed in [any of the claims 1-2 or 9-10] claim 1 . 
characterized in that said mobility functions (M) in the form of two brokers allows for 
interaction between an object (COl) belonging to a user domain and an object (C02) 
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belonging to a telecom system domain by letting said interactions enter said mobility 
functions (M) at one end and exit therefrom at the other end [(Fig. 5)], 

12. (Amended) Arrangement as claimed in [any of the claims 1-2 or 9-11] claim 1 . 
characterized in that both ends of the mobility functions (M) support both the same interface 
type containing an "invoke type" operation, for thereby allowing a request to be built and 
invoked dynamically by client objects. 

14. (Amended) Arrangement as claimed in [any of the claims 1-2, or 9-13] claim 1 . 
characterized in that the mobility functions (M) are introduced in the system architecture as a 
functional layer between the application layer and the DPE layer, said layer separation 
allowing every layers to use services offered by other layers. 

15. (Amended) Arrangement as claimed in [any of the claims 1-2, or 9-14] claim 1 . 
characterized in that there is introduced an intermediary model called derived computational 
model in the transition from the computational model to the engineering model, said 
intermediary model being used to map all interactions traversing the boundary between the 
user domain and the telecom system domain to interactions with the mobility functions (M). 

16. (Amended) Arrangement as claimed in claim 15, characterized in that on the basis 
of the derived computational model, an engineering model can be elaborated and engineering 
objects, such as stubs, can be mechanically generated. 

17. (Amended) Arrangement as claimed in [any of the claims 1-2] claim 1. 
characterized in that said arrangement comprises proxy objects, a proxy acting on behalf of 
an entity in a transparent way, i.e. # when interacting with a proxy an entity cannot tell 
whether it is dealing with the real counterpart or with its proxy. 

21. (Amended) Arrangement as claimed in [any of the claims 1-2 or 17-20], 
characterized in that there is introduced an object type designated Dynamic Object (DO), all 
proxies being of the type DO, and that a proxy, i.e. ^ an object (instance) of type DO is 
initiated from an object template called Dynamic Object Implementation (DOI). 
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23. (Amended) Arrangement as claimed in [any of the claims 1-2 or 17-22] claim 1 . 
characterized in that any object wanting to interact with objects in a different domain are 
registered in the mobility functions (M), the registration of the necessary objects for an 
application being done for example at the [initialisation] initialization by an object which is 
[customised] customized for the configuration, the definition and creation of a proxy 
conveniently being done together with the registration of the object it is representing. 

25. (Amended) Arrangement as claimed in [any of the claims 1-2 or 17-24] claim 1 , 
characterized in that there is introduced a new redirection function on the DPE in question, 
as well as the possibility of generating special stub for any dynamic objects. 



By the foregoing amendment Applicant has eliminated the multiple claim dependencies 
of claims 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 17, 21, 23, and 25 in order to minimize the filing fee. 
Applicant has also corrected minor typographical errors appearing in claims 3, 5, 6, 16, 17, 21, 



REMARKS 



and 24. 



Prompt and favorable examination on the merits is respectfully requested. 



Respectfully submitted, 



NIXON & VANDERHYE P.C. 



By: 




John R. Lastova 
Reg. No. 33,149 



JRL:mm 

1100 North Glebe Road, 8th Floor 



Arlington, VA 22201-4714 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 
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ARRANGEMENT FOR SIMPLIFYING THE DESIGN AND IMPLEMENTATION 
OF MOBILE SERVICES IN A COMMUNICATION SYSTEM 

FIELD OF THE INVENTION 

5 

The present invention relates to an arrangement for sim- 
plifying the design and implementation of mobile services 
in a communication system, especially a telecommunication 
system, said system comprising distributed hardware and 
10 software components which interact in order to provide 
services to one or more users . 

BACKGROUND OF THE INVENTION 

15 The present invention has been developed on the basis 
that prior art defined distribution transparencies are 
not sufficient to support mobility. 

More specifically the present invention has been devel- 
2 0 oped on the basis of considering mobility as an addi- 
tional transparency. 

In other words, the invention suggests the provision of 
the mobility support functions in a transparent way, i.e. 

25 the application designer needs not to be aware or con- 
cerned about the necessary mechanisms and function to 
support mobility and can concentrate on his application 
design. Mobility can hence be considered as a new trans- 
parency in addition to the ones defined by ODP (Open Dis 

30 tributed Processing) [ITUa] and adopted by TINA (Telecom 
raunication Information Networking Architecture) [TIN95i] 



According to ODP/TINA, a telecommunication application i 
realized by a set of interacting computational objects 
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which rely on an abstract infrastructure called Distrib- 
uted Processing Environment (DPE) . The DPE hides the com- 
plex details of mechanisms used to overcome problems 
caused by distribution. 

5 

The process of hiding the effect of distribution is known 
as distribution transparency in the Open Distributed 
Processing Reference Model (RM-ODP) . The application de- 
signers do not need to be aware of the mechanisms neces- 

10 sary to deal with different aspects of distribution and 
can therefore focus on their application specification. 
When addressing the distribution of their applications, 
they only have to express their requirements for trans- 
parencies. The properties of distribution is hidden or 

15 transparent to the end-users and the application design- 
ers in the enterprise, information and computational 
viewpoints . 

The engineering viewpoint defines the mechanisms and 

2 0 functions by which those transparencies are realised. 

Each set of transparency properties requires the use of a 
set of standard functions in a specified way. 

The distribution transparencies defined by ODP/ TINA are: 
25 • Access transparency 

• Location transparency 

• Federation transparency 

• Migration transparency 

• Transaction transparency 

3 0 • Replication transparency 

• Failure transparency 

• Resource transparency 

• Concurrency transparency 
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As shown in Figure 1, a DPE consists of several DPE nodes 
A, B and C. A DPE node is a unit of resource administra- 
tion providing support to the DPE architecture. The part 
of the DPE node supporting the DPE architecture is called 
5 a DPE platform. The computing resource supporting a DPE 
platform is called Native Computing and Communication En- 
vironment (NCCE) . Even if the NCCE can itself be locally 
distributed, there is only one DPE platform associated 
with a DPE node. 

10 

A DPE platform shields the objects from the potential 
heterogeneity of the NCCE on which they are executed. Not 
all the transparencies are required to be provided by a 
DPE platform but only the ones called fundamental. Access 
15 transparency and location transparency are the two trans- 
parencies which are considered fundamental in the DPE ar- 
chitecture . 

STATE OF THE ART 

20 

Mobility support functions are implemented and offered in 
different systems such as UPT (Universal Personal Tele- 
communication) and networks such GSM (Global Mobil Sys- 
tem) but never in a transparent way. In order to build 

25 new application, the designers must take into account and 
know fairly well about the mobility support functions. 
ODP/TINA introduced an efficient framework for designing 
and implementing distributed applications but assume that 
mobility is inherently supported. In fact, mobility is 

3 0 not inherently supported. When a terminal which is a DPE 
node is moving, disappearing and reappearing some moment 
later at another place, additional mobility functions 
must be introduced and preferably in a transparent way. 
In other words, mobility transparency is required. 
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PROBLEMS RELATED TO PRIOR ART 

The design of mobile applications, i.e. applications 
5 available to the mobile users, is complex and time- 
consuming because the designer has to take into account 
mobility functions which are quite complex and numerous. 
It is also difficult and time-consuming to make existing 
fixed applications available to mobile users, i.e. mobile 
10 without mobility transparency. 

OBJECTS OF THE PRESENT IT* ,'ENTION 

An object of the present invention is to improve the 
15 availability of services in a communication system espe- 
cially as seen from an application designer's point of 
view. 

Another object of the present invention is to provide the 
20 application designer with a tool which is not concerned 

about the necessary mechanism and function regarding sup- 
porting mobility. 

Yet another object of the present invention is to provide 
25 the designer of applications with a tool whereby the de- 
signer has not to take into account mobility functions. 

Still another object of the present invention is to pro- 
vide a tool by which the designer of applications can 
30 make fixed applications available to mobile users in a 
simplified and less time-consuming way. 

SUMMARY OF THE INVENTION 
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The above objects are achieved in an arrangement as 
stated in the preamble, which according to the present 
invention is primarily characterized by introducing in 
said system a mobility transparency, for thereby enabling 
5 facilitated application design included inter alia termi- 
nal or personal mobility, as well as session mobility 
both in a continuous way and in a discrete way. 

In other words, it is according to the present invention 
10 suggested a new transparency, called mobility transpar- 
ency which is introduced and has for its main object to 
hide all the necessary mechanisms and functions to sup- 
port mobility to the application and the application de- 
signer. According to the present invention this mobility 
15 transparency can also be considered as a new transparency 
in addition to already existing transparency, for example 
in addition to the ones defined by ODP (Open Distributed 
Processing) and adapted by TINA (Telecommunication Infor- 
mation Networking Architecture) . 

20 

Further features and advantages of the present invention 
will appear from the following description taken in con- 
nection with the enclosed drawings, as well as from the 
appending patent claims. 

25 

BRIEF DISCLOSURE OF THE DRAWINGS 

Fig. 1 illustrates schematically a physical infrastruc- 
ture relating to a distributed processing environment 
30 (DPE) consisting of several DPE nodes. 

Fig. 2 illustrated schematically the mobility functions 
which will be implemented according to the present inven- 
tion. 
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Fig. 3 is an example of an embodiment according to the 
present invention, wherein the mobility functions are to- 
tally integrated in the infrastructure of platform, rep- 
5 resenting the in-line alternative. 

Fig. 4 is a schematical block diagram illustrating an- 
other field of application according to the present in- 
vention, wherein the broker in client /server interactions 
10 are utilised. 

Fig. 5 is a schematical diagram illustrating the embodi- 
ment wherein the user agents are acting as routing bro- 
kers . 

15 

Fig. 6 is a schematical diagram illustrating further de- 
tails of an embodiment including the broker alternative. 

Fig, 7 is a schematical block diagram illustrating still 
20 another embodiment of the present invention, wherein 

proxies are used to untie the binding between the appli- 
cation and the mobility functions. 

Fig. 8 illustrated schematically possible configurations 
25 at run- time. 

Fig. 9 illustrates an information model for the proxy. 

Fig. 10 illustrates schematically the relationship be- 
30 tween objects, interfaces and identifiers in the computa- 
tional and engineering viewpoints. 

Fig. 11 illustrates further details related to the redi- 
rection of operation request to the proxy. 
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Fig. 12 is a schematical diagram illustrating the compu- 
tational model of the application in the proxy alterna- 
tive, especially related to the configuration of the ap- 
5 plication at installation by which the plant engineer can 
derive the registration of objects to the mobility func- 
tions and the creation of necessary proxies. 

DETAILED DESCRIPTION OF EMBODIMENTS 

10 

In the following there will be given detailed descrip- 
tions of embodiments according to the present invention. 

As stated in the preamble, the main object of the present 
15 invention is to introduce a so-called mobility transpar- 
ency in order to hide all the necessary mechanisms and 
functions to support mobility to the application and the 
application designer. 

20 In the following there will be discussed three alterna- 
tive solutions in which mobility transparency can be pro- 
vided, namely by the in-line alternative, by the broker 
alternative, as well as by the proxy alternative. 

25 As previously discussed in connection with Fig. 1 a tele- 
communication application is realised by a set of inter- 
' -acting computational objects which rely on an abstract 
infrastructure called Distributed Processing Environment, 
DPE, said DPE hiding the complex details of mechanisms 

3 0 used to overcome problems caused by distribution. Fur- 
ther, as appearing from Fig. 1 a DPE consists of several 
DPE nodes A, B and C, a DPE node being a unit of resource 
administration providing support to the DPE architecture. 
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Now, turning to Fig. 2 there is illustrated a block des- 
ignated M, which represents all the functions necessary 
to support mobility, such as terminal support functions, 
personal support functions, session support functions, 
5 mobility-related support functions, etc. 

In the following there will successively be disclosed how 
M is introduced into the whole system in all three alter- 
natives . 

10 

THE IN-LINE ALTERNATIVE 

The most straightforward alternative to make mobility 
transparent to the application designers at the require - 

15 raents and functional specification phases, is to inte- 
grate the mobility functions M totally into the infra- 
structure or platform. All the computational objects will 
not be mapped to basic engineering objects (BEO) but to 
engineering objects (EO) and will hence not be visible in 

20 the computational model of the application. In fact, the 
mobility function constitutes the engineering object in- 
terceptor, standing at the boundary of two domains: the 
terminal domain and the telecom system domain. This solu- 
tion is also called in-line because the support of mobil- 

25 ity is introduced directly embedded into the platform. 

In Figure 3, we show as example an application consisting 
of four computational objects C01, C02 , C03 and C04 . C01 
and C02 are grouped together into cluster 1 and belong to 
3 0 the user domain. C03 and C04 belong to the telecom system 
domain but are assigned to clusters 2 and 3 . 



From the given computational model, an engineering model 
can be developed. Each Computational Object (CO) is 
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mapped to a Basic Engineering Object (BEO) . Of course, a 
CO can also be mapped to several BEOs but for the sake of 
simplicity we do not choose this mapping here. Since COl 
and C02 are within the same cluster, interactions between 
5 them can be done directly as method calls. Communications 
between C03 and C04 go through a channel consisting of 
stubs, binders and protocols since they belong to differ- 
ent clusters. Communications between C02 and C03 go also 
though a channel because C02 and C03 reside in different 

10 clusters, but the channel will now contain an interceptor 
in addition to the usual objects because it crosses the 
boundary between two domains (terminal domain and telecom 
system domain) . However, the interceptor is not visible 
for the application designer and does not have any conse- 

15 quence for the application objects. It is worth noting 
that the application designer does not need to think 
about the terminal domain in the computational model (up- 
per part of Figure 3) . In the engineering model (lower 
part of Figure 3) there is also drawn a borderline be- 

20 tween the application layer and the DPE/platform layer. 

This borderline is in fact not a real and existing border 
but just a virtual one. In showing that, we aim to visu- 
alise that the mobility functions M is fully integrated 
in the DPE. 

25 

If the mobility functions M is implemented and fully in- 
tegrated into the platform and there exist development 
tools able to generate channels containing the mobility 
functions as interceptor, then the design and implementa- 
3 0 tion of mobile applications are no more complex than the 
ones of fixed applications. From the computational model, 
in addition to the usual grouping of objects into clus- 
ters, capsules, etc., the application designer has to de- 
cide whether an object belongs to the user domain or the 
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telecom system domain. Once the decisions are made, the 
necessary objects such as stubs can be generated for all 
the applications objects. The application designer just 
need to implement the programming codes which are spe- 
5 cific to his application domain. 

The presented alternative has many advantages. It suc- 
ceeds in making mobility transparent to the applications. 
It can be optimised to become very efficient. It is also 
10 conformed to the RM-ODP specifications concerning the 
channel concept . 

There are however some disadvantages. From the applica- 
tion point of view, there may be a lack of flexibility in 

15 the sense that objects, once allocated, are not allowed 
to migrate from the user domain, i.e. from the mobile 
side of the system to the telecom system domain or vice 
versa. The boundary between the user domain and the tele- 
com system domain constitutes a very rigid borderline 

2 0 which may not be wanted. From the platform point of view 
and also from the mobility functions point of view, it 
may not be desirable to tie closely the mobility func- 
tions to the platform. The platform should be general 
enough to fit most distributed systems without major 

25 modifications, while the mobility functions, as its name 
tells, should be generic and easy to be customised for a 
specific system. It is therefore desirable that the con- 
struction of the platform and the mobility functions 
could be done independently and by different parties. 

30 

THE BROKER ALTERNATIVE 



The broker concept 

In this alternative, we introduce and use a notion called 
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broker defined in "Understanding Corba" [OPR96] . A broker 
is a specialised server object acting as intermediary be- 
tween one or more client objects and one or more server 
objects. As shown in Figure 4, a broker represents a cli- 
5 ent when the client makes a request to a server and rep- 
resents a server when a server makes a response to a cli- 
ent . 

There are defined two brokering schemes : 

10 

1 . Introduction brokering 

In an introduction brokering scheme active servers 
register with the broker to make themselves known in 
the system. The client can then send a message to 

15 the broker asking for a server that can perform some- 

task. The introduction broker selects a server to 
perform the task and returns information to the cli- 
ent accessing that server. The broker introduces the 
server to the client, so that the client and the 

2 0 server can contact each other directly. This broker- 

ing scheme corresponds the RM-ODP trading function 
[ITUc] . 

2 . Routing brokering 

25 In a routing brokering scheme, the clients sends, a 

message to the broker asking for a server that can 
perform some task. The routing broker then selects a 
server to perform the task and sends the client 1 s 
request to that server. The broker handles all com- 

30 munications; no direct communication between the 

client and the server ever takes place. 
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MOBILITY FUNCTIONS M AS ROUTING BROKER 

In the second solution we adopt the concept of routing 
brokering with a minor modification. The client send a 
5 message to the routing broker not asking for any server 
able to perform the task but asking for a definite server 
to perform this task. The broker locates the server and 
sends the client's request to that server. The mobility 
functions M will play the broker role. And since an ob- 
10 ject may play both the roles of client and server, the 
mobility function M will be a a cascade of two brokers. 

The Figure 5 shows how an object COl belonging to the 
user domain interacts with an object C02 belonging the 
15 telecom system domain. Interactions enter the mobility 
functions M at one end and exit at the other. 

Both ends of the mobility functions M support both the 
same interface type containing an "invoke type" opera- 

2 0 tion. This operation originates from the same concept as 

the one used in the Dynamic Invocation Interface (DID 
defined in CORBA [OPR96] , [Obja] . This concept allows re- 
quest to be built and invoked dynamically by client ob- 
jects. The client object needs to know interface-related 
25 information only at the invocation time. No knowledge is 
necessary at compilation time. The Invoke is composed of 
an object name {or identifier) , an operation name, and a 
parameter list for the invoked operation. 

3 0 An IDL (Interface Definition Language) [Obja] of such In- 

voke operation is given below. 

The name is the name or identifier of the object where 
the call is to be made. The ctx contains information 
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about the client object, environment, or circumstances of 
a request that are convenient to pass as parameters. The 
operation is the same operation identifier that is speci- 
fied in the interface definition of the server object, 
5 The arg_JList contains a list of arguments for the opera- 
tion. The operation result will be placed in the result 
argument after the invocation completes. 



Interface Moblnvocation { 
10 Invoke ( in Object target; 

in Context ctx; 
in Identifier operation; 
in NVList arg_list; 
inout NamedValue result 

15 

}; 

IDL specification of the Moblnvocation interface 

The application designer can decide how a client object 
20 can call the operation Invoke of the mobility functions 
M. If calls are to be made in a static way then the stub 
generated from the interface Moblnvocation must be in- 
cluded in the client object code at compilation time. If 
calls are to be made dynamically, e.g through the Dynamic 
25 Invocation Interface (DII) [Objb] , than the information 
about the interface Moblnvocation is only needed at run 
time but not at compilation time. 



/ /obj ect to be 
//context of op 
//intended ope 
//args to op 
//operation re 



After entering the mobility functions at the first end 
30 and traversing several other objects, the invocation ar- 
rives at the other end. In order to avoid a static bind- 
ing between the mobility functions M and an arbitrary ob- 
ject, and allowing independent development, the DII is 
again used. Hence, the mobility functions M does not need 
3 5 any interface information of the server object at compi- 
lation time. 
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In this alternative, the mobility functions M is intro- 
duced in the system architecture as a functional layer 
between the application layer and the DPE layer. It is 
5 worth noting that the mentioned layer separation is func- 
tional and not hierarchical in the sense that every lay- 
ers can use services offered by other layers. Assuming 
that the interfaces between layers are well defined, the 
inside structure of a layer is not relevant to other lay- 
10 ers and can be modified without any serious implications. 

Let us now return to the same example as in the previous 
paragraph with four computational objects COl , C02 , C03 
and C04 . As shown in Figure 12, we start with the same 
15 computational model but an intermediary model called de- 
rived computational model is introduced in the transition 
from the computational model to the engineering model. 
This intermediary model is used to map all interactions 
traversing the boundary between the user domain and the 

2 0 telecom system domain to interactions with the mobility 

functions M. From the derived computational model, an en- 
gineering model can be elaborated and engineering objects 
such as stubs can be mechanically generated. 

25 This alternative has several merits. First, the mobility 
transparency is still preserved at the computational 
viewpoint. Although an additional model is necessary in 
the transition to the engineering viewpoint, it does not 
constitute a major obstacle since the derived computa- 

3 0 tional model can be easily and automatically derived from 

the computational model. 

However, there is still one major limitation. As with the 
previous alternative, migration of objects across domain 
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boundaries is not allowed. Once allocate to a domain, an 
object is not allowed to move since interactions across 
domain boundaries are statically mapped to interactions 
with the mobility functions M. Objects originally de- 
5 signed without inter-domain interaction capability can 
not later on communicate with objects in other domains 
without modification and re-compilation. 

THE PROXY ALTERNATIVE 

10 

This alternative aims to enhance further the flexibility 
offered by the previous alternative by loosening the 
closed binding between the application and the mobility 
functions M. This is achieved by introducing proxy ob- 
15 jects. A proxy acts on behalf of an entity in a transpar- 
ent way, i.e. when interacting with a proxy, an entity 
cannot tell whether it is dealing with the real counter- 
part or with its proxy. 

20 Every object requiring inter-domain interactions is rep- 
resented by a proxy object located in the same domain as 
the object interacting with it. When interacting with an 
object in a different domain, the object is actually in- 
teracting with the local proxy object of the required ob- 

25 ject of the other domain. The proxy will marshall the op- 
eration invocation into the invoke operation (as defined 
in the previous paragraph) at the respective end of M. If 
interactions are to be in both directions, we need a sym- 
metrical constellation as shown in Figure 7. In this ex- 

3 0 ample an object COl in the user domain wants to invoke an 
operation OpX() on an object C02 in the telecom system 
domain. COl is actually invoking OpX on the proxy of C02 , 
namely PC02 . PC02 will marshall OpX() into the Invoke op- 
eration of M. This operation will be conveyed through the 
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mobility functions to the other end and M invokes OpX{) 
on C02. The result will be conveyed all the way back to 
C01. It is worth noting that only PC02 , the proxy of C02 , 
is involved in the invocation of operations on C02 and 
5 PC01, the proxy of COl is left outside in this case. The 
opposite situation will occur when C02 calls operation on 
COl. 

It is observed that PC02 has an interface which has the 
10 same signature as the one of C02 . All operations defined 
for C02 are defined for PC02 . However, all the operations 
of PC02 will perform exactly the same job which is to 
marshall the initial operation and to call the Invoke op- 
eration of M. 

15 

COl may invoke the operation on C02 in a static way or 
through the Dynamic Invocation Interface (DII) . In the 
first case, the information about the interface of C02 
must be defined and available at compilation time. In the 
20 second case, this information is only needed at run time. 

Until this stage, the level of flexibility achieved is 
not higher than in the first alternative. In fact, the 
flexibility relies on how the proxies are introduced and 

25 created. If the introduction and creation of necessary 
proxies are based on the domain grouping of objects and 
decided at compilation time, then we return to a solution 
quite similar to the first alternative. The proxy must 
somehow be created according to the communications needs 

30 and dynamically at run-time to achieve higher level of 
flexibility. 

Figure 8 shows two run-time configurations. By domain, it 
is meant either user domain or telecom system domain. If 
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at run time COl and C02 are within the same domains, then 
interactions are done through usual channels assuming of 
course that the access and location transparencies are 
supported within the domain. On the other hand, if they 
5 are in different domains, e.g. one object in the user do- 
main and the other in the telecom system domain, then a 
proxy is created to transfer all the interactions to the 
mobility functions which is responsible to deliver them 
to the other side. Neither COl nor C02 need to be aware 

10 that the proxy PC02 exists. COl does not distinguish be- 
tween PC02 and C02 when it is invoking operations. C02 
does not distinguish between PC02 and COl when it is in- 
voked. It should also be possible to design and implement 
PC02 independently of both COl and C02 . It should also be 

15 possible to create proxies dynamically at run-time when 
interactions across domain boundary are requested. 

To fulfil the requirements mentioned above, we adopt the 
idea presented by OMG in the Dynamic Skeleton Interface 

2 0 (DSI) . The purpose for the introduction of the DSI is to 

enable the building of bridges interconnecting multiple, 
heterogeneous CORBA- compliant ORBs . However, the DSI is 
described in CORBA terminology and in CORBA- compliant 
manner which is not always consistent with the ODP/TINA 
25 concepts. We shall attempt here to map all the ideas to 
the ODP world and give a description which fits better 
with our context . 

The idea is to introduce an object type called Dynamic 

3 0 Object (DO) . All the proxies will be of type DO. A proxy, 

i.e. an object (instance) of type DO is instantiated from 
an object template called Dynamic Object Implementation 
(DOI) . A proxy is hence semantically separated from the 
object it represents. The unique relationship which re- 
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mains between them is Represent, i.e. a proxy represents 
one and only one object. A proxy shall be deleted when 
the represented object terminates. An object can, how- 
ever, be represented by multiple proxies, e.g. one proxy 
5 for each client object. An information model is given in 
Figure 9 . 

The object type DO has a unique interface which consists 
of only one operation, namely Invoke, which is similar to 
10 the Invoke operation previously shown. 

For an arbitrary object to interact with an object resid- 
ing in a remote domain, a proxy representing the remote 
object must be present in the local domain. There are now 

15 two problems to solve. First, when an object invokes an 
operation on a remote object, the invocation must be re- 
directed toward the proxy. Both a naming conversion and 
an object type conversion are necessary because the cli- 
ent generates an operation request using the reference of 

20 the remote server which implicitly refers to the object 
type of the server object. Second, the operation request 
must be translated and marshalled into the Invoke opera- 
tion which is the only operation of the proxy. 

25 To preserve transparency, these two problems must and can 
only be solved in the Engineering viewpoint and not in 
the Computational viewpoint. Correspondence must, how- 
ever, exist between the two viewpoints. 

3 0 Let us reconsider the example of a computational object 
COl invoking an operation OpX on a remote computational 
object C02 . When requesting an operation OpX on C02 , COl 
has to specify the Computational Interface Identifier 
(CII, also called Computational Interface Reference in 
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TINA [TIN95a] of the interface 12 of OD2 , (say C02.I2) 
and the operation name OpX plus all the necessary opera- 
tion arguments. 

5 Let us now move to the engineering viewpoint . Suppose 

that C01 and C02 are mapped to the basic engineering ob- 
jects BEOl and BE02 , respectively. Depending on the ap- 
plication designer's decision, the operation request can 
be built in a static way before compilation or dynami- ' 

10 cally at run-time. This will lead to different types of 
stubs that should be linked and compiled together with 
the programming code of BEOl. In the first case, the gen- 
erated stub is specific to the interface C02.I2 while in 
the second case the stub is generic and can be used by 

15 any object and in any binding. Dynamic Invocation Inter- 
face is an example of the second case. However, in both 
cases, the engineering operation request must contain the 
same information as the corresponding computational op- 
eration request, i.e. the Computational Interface identi- 

20 fier, the operation name and parameters. 

At run- time, when an operation request is issued, a chan- 
nel must be established to interconnect the involved ba- 
sic engineering objects. The necessary information to 
25 create a channel is contained in an Engineering Interface 
Reference (EIR) [ITUc] . Contrary to the CII, the EIR is 
both time and space dependent. The relationship between 
CII and EIR is shown in Figure 10. 

3 0 The DPE or more specifically the nucleus of the DPE node 
where the call is issued, , will be implicated to map the 
incoming CII to an EIR. This can be done in different 
ways, for instance, as an exception call in the stub 
code. The EIR will be used to establish the channel. 
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In our example, no EIR will be found for BE02 since it is 
residing in another domain. Here, the DPE can be equipped 
with a redirection function which maps the incoming CII, 
5 i.e. the CII of BE02, to the EIR of the proxy PBE02 in- 
stead of the EIR of BE02. The mapping is forced in the 
sense that the proxy PBE02 does not support the interface 
C02.I2 and the operation OpX. A channel can now be estab- 
lish between BEOl and PBE02 . When the operation request 
10 arrives at the end of the channel, a conversion is neces- 
sary before the delivery to PBE02 . The server stub of 
PBE02, instead of performing the usual unmarshalling of 
the request, has to convert it and pack it into the op- 
eration Invoke of the PBE02 which may look like this: 

15 

Invoke (C02.I2, Context, OpX, Arguments, Result) 

The OMG's Dynamic Skeleton Interface allows indeed the 
specification of such flexible interface for a server ob- 

20 ject and the generation of stub from the interface speci- 
fication. By this technique, the interface and operation 
name specified by the client object does not have to 
match with the interface and operations defined at the 
server object and can be compiled separately* In CORBA 

25 revision 2.0, there is also defined a redirection func- 
tion as described above which supports the DSI . 

The operation Invoke of PBE02 can now be designed to con- 
tain a call to tlie operation Invoke of the user agent of 
30 the mobility functions. By this way, the operation re- 
quest is passed to the mobility functions and conveyed 
from one domain to the another domain across the bound- 
ary. When receiving the request, the user agent in the 
other domain will invoke the operation OpX() on BE02 . The 
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result can then be conveyed the same way back, first to 
the PBE02 and then finally to BEOl . In Figure 11, the ad- 
ditional redirection function of the DPE and the special 
server stub of PBE02 are emphasised by using darker col- 
5 our than on other DPE 1 s objects. 

By using the proxy objects as described above, greater 
flexibility is achieved. The application designer does 
not have to perform the domain allocation of his objects, 

10 i.e. to decide which objects should be allocated to which 
domain in the implementation phase. Only the usual group- 
ing of objects into clusters, capsules and nodes is re- 
quired in the transition from the computational viewpoint 
to the engineering viewpoint. Necessary stubs and skele- 

15 tons can then be generated automatically from the compu- 
tational specifications by the development tools. The ap- 
plication designer can proceed with the implementation of 
application specific programming code. The implementation 
of the application is completed with the linking and com- 

20 pilation of the application code and the generated stubs. 

The definition and creation of proxy objects can be post- 
poned until the configuration and deployment of the ap- 
plication. Depending upon the chosen configuration, the 

25 necessary proxy objects will be identified and defined. 
The proxies can be created at the initialisation of the 
application and remain alive during the whole life time 
of the application. They can also be created dynamically 
according to the* interactions and terminate upon the com- 

30 pletion of the interaction. 



Any object wanting to interact with objects in a differ- 
ent domain must be registered in the mobility functions. 
The registration of the necessary objects for an applica- 
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tion can be done at the initialisation by an object which 
is customised for the configuration. The definition and 
creation of a proxy can be conveniently done together 
with the registration of the object it is representing. 

5 

In order to recapitulate what is achieved in this alter- 
native, let us return to the same example considered in 
the two previous alternatives with for computational ob- 
jects C01, C02, C03 and C04 . In this alternative, it is* 

10 not necessary to do the domain grouping in the transition 
from the computational viewpoint to the engineering view- 
point. Only the grouping of objects into clusters, cap- 
sules and nodes is performed. C01 and C02 belong to the 
cluster 1, C03 to cluster 2, C04r to cluster 3. The clus- 

15 ters 1, 2 and 3 are respectively within capsule A, cap- 
sule B and Capsule C. From this computational model, an 
Engineering model is derived and the necessary stubs are 
generated. Between C02 and C03 , there is a need for a 
channel. The same applies to C03 and C04 . Note that in 

20 this model all objects, clusters, capsules and nodes are 
considered as if they are all located within the same do- 
main. The application designer can now add application 
specific programming code and execute the linking and 
compilation. The design and implementation of the appli- 

25 cation is then completed. 

At installation, the plant engineer configures the appli- 
cation according to the request of the customer. Based on 
the configuration, he can derive the registration of ob- 
30 jects to the mobility functions and the creation of nec- 
essary proxies {see Figure 12) . 

This alternative yields very high level of flexibility. 
The inconveniences are the requirement for a new redirec- 
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tion function on the DPE and the possibility to generate 
special stub for the dynamic objects. These two inconven- 
iences are however insignificant since DPE ' s such as 
CORBA revision 2.0 implementations already include these 
5 features . 

MERITS OF THE INVENTION 

• By introducing Mobility transparency, i.e. hiding the 
10 mobility functions to the applications, the design and 

implementation of mobile applications will be no more 
complex than the designing and implementation of fixed 
applications . 

15 • Existing fixed applications may be transformed to mo- 
bile application, i.e. made available to mobile users 
without any modification. 
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Patent claims 



1. Arrangement for simplifying the design and implemen- 
tation of mobile services in a communication system, es- 

5 pecially a telecommunications system, said system com- 
prising distributed hardware and software components 
which interact in order to provide services to one or 
more users, 

characterized by introducing in said system 
10 a mobility transparency, for thereby enabling facilitated 
application design including inter alia terminal or per- 
sonal mobility. 

2. Arrangement as claimed in claim 1, 

15 characterized in that said mobility 

transparency is adapted to hide all the necessary mecha- 
nism and functions, for thereby supporting mobility to 
the application in question and to the application de- 
signer. 

20 

3 . Arrangement as claims in claim 1 or 2 , 
characterized in that said mobility 
transparency is to be considered as a new transparency in 
addition to already existing transparency, for example in 
25 addition to the one defined by ODP (Open Distributed 

Processing) and adopted by TINA (Telecommunication Infor- 
mation Networking Architecture) . 



4. Arrangement as claimed in any of the claims 1-3, 
30 characterized in that mobility transpar- 
ency is introduced to the application designers at the 
requirement and functional specification phases, i.e. by 
integrating mobility function (M) totally into the infra- 
structure of platform. 
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5. Arrangement as claimed in any of the preceding 
claims , 

characterized in that computational ob- 
5 jects are mapped to engineering objects (EO) so as to be 
none-visible in the computational model of the applica- 
tion in question. 

6 . Arrangement as claimed in any of the preceding 
10 claims, 

characterized in that the mobility func 
tion constitutes the engineering object interceptor, i.e 
being arranged at the boundary between the terminal do- 
main and the telecom system domain. 

15 

7. Arrangement as claimed in any of the preceding 
claims, 

characterized in that an engineering 
model is developed by letting each computational object 

2 0 (CO) be mapped to one or more Basic Engineering Objects 
(BEOs) , interaction between computational objects (COl, 
C02) belonging to the same cluster being effected di- 
rectly as method calls , and communications between compu 
tunal objects (C03, C04) located in the telecom system 

25 domain and in different clusters being effected through 
channel comprising stubs, binders and protocols. 

8 . Arrangement as claimed in any of the preceding 
claims, 

30 characterized in that communication be- 
tween user domain computation objects (C02) and telecom 
system domain computation object (C03) residing in dif- 
ferent clusters will take place in a channel comprising 
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an interceptor ( ) in addition to the usual objects, said 
interceptor being invisible for the application designer. 

9. Arrangement as claimed in any of the preceding 
5 claims, 

characterized in that from the computa- 
tional model the application designer can decide whether 
an object belongs to the user domain or the telecom sys- 
tem domain, for on the basis of such a decision to gener- 
10 ate the necessary objects, such as stubs, for all the ap- 
plication objects . 

10. Arrangement as claimed in any of claims 1-3, 
characterized in that the arrangement 

15 comprises means for sending a message to a routing broker 
asking for specific server to perform a task, said bro- 
ker locating the server and sending said request to said 
server, said mobility functions (M) thereby playing the 
role as the broker. 

20 

11. Arrangement as claimed in any of the claims 1-3 or 
10, 

characterized in that said mobility 
function (M) comprises a cascade of two brokers. 

25 

12. Arrangement as claimed in any of the claims 1-3 or 
10-11, 

characterized in that said mobility 
functions (M) in ; the form of two brokers allows for in- 
3 0 teraction between an object (COl) belonging to a user do- 
main and an object (C02) belonging to a telecom system 
domain by letting said interactions enter said mobility 
functions (M) at one end and exit therefrom at the other 
end (Fig. 5) . 
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13. Arrangement as claimed in any of the claims 1-3 or 
10-12, 

characterized in that both ends of the 
5 mobility functions (M) support both the same interface 
type containing an "invoke type" operation, for thereby 
allowing a request to be built and invoked dynamically by 
client objects. 

10 14. Arrangement as claimed in claim 13, 

characterized in that there is used an 
invoke operation, which invoke comprises an object name 
(or identifier) , an operation name, and a parameter list 
for the invoked operation. 

15 

15. Arrangement as claimed in any of the claims 1-3, or 
10-14, 

characterized in that the mobility func- 
tions (M) are introduced in the system architecture as a 
20 functional layer between the application layer and the 

DPE layer, said layer separation allowing every layers to 
use services offered by other layers. 

16. Arrangement as claimed in any of the claims 1-3, or 
25 10-15, 

characterized in that there is intro- 
duced an intermediary model called derived computational 
model in the transition from the computational model to 
the engineering model , said intermediary model being used 
3 0 to map all interactions traversing the boundary between 

the user domain and the telecom system domain to interac- 
tions with the mobility functions (M) . 

17. Arrangement as claimed claim 16, 
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characterized in that on the basis of 
the derived computational model, an engineering model can 
be elaborated and engineering objects, such as stubs, can 
be mechanically generated. 

5 

18. Arrangement as claimed in any of the claims 1-3, 
characterized in that said arrangement 
comprises proxy objects, a proxy acting on behalf of an 
entity in a transparent way, i.e. when interacting with a 

10 proxy an entity cannot tell whether it is dealing with 
the real counterpart or with its proxy. 

19. Arrangement as claimed in claim 18, 
characterized in that the proxy is 

15 adapted to marshall the operation invocation into an in- 
voke operation at the respective end of the mobility 
functions (M) . 

20. Arrangement as claimed in claim 19, 

20 characterized in that the proxy is in- 
troduced as a symmetrical constellation if interactions 
are to be in both directions. 

21. Arrangement as claimed in claim 20, 

25 characterized in that the necessary 

proxies are introduced and created according to the com- 
munications needs, alternatively dynamically at run- time. 

22. Arrangement "as claimed in any of the claims 1-3 or 
30 18-21, 

characterized in that there is intro- 
duced an object type designated Dynamic Object (DO) , all 
proxies being of the type DO, and that a proxy, i.e. an 
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object (instance) of type DO is initiated from an object 
template called Dynamic Object Implementation (DOI) . 

23. Arrangement as claimed in claim 22, 

5 characterized in that a proxy represents 
one and only one object, a proxy being deleted when the 
represented object terminates, alternatively that an ob- 
ject can be represented by multiple proxies, e,g. one 
proxy for each client object. 

10 

24. Arrangement as claimed in any of the claims 1-3 or 

18- 23, 

characterized in that any object wanting 
to interact with objects in a different domain are regis- 

15 tered in the mobility functions (M) , the registration of 
the necessary objects for an application being done for 
example at the initialisation by an object which is cus- 
tomised for the configuration, the definition and crea- 
tion of a proxy conveniently being done together with the 

2 0 registration of the object it is representing. 

25. Arrangement as claimed in claim 24, 

characterized in that only the grouping 
of objects into clusters, capsules and nodes is per- 
25 formed, all objects, clusters, capsules and nodes being 

considered as if they are all located within the same do- 
main, the application designer adding thereto specific 
programming code and executing the linking and compila- 
tion. : 

30 

26. Arrangement as claimed in any of the claims 1-3 or 

19- 25, 

characterized in that there is intro- 
duced a new redirection function on the DPE in question, 
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as well as the possibility of generating special stub for 
any dynamic objects. 
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Figure 3 The In-line alternative 
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Figure 7 Using proxies to untie the binding between the 
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Figure 8 Possible configurations at run-time 
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Figure 1 1 The redirection of operation request to the proxy 
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Figure 12 The Proxy alternative 



